Business Requirements Document (BRD)

AquaX — Shrimp Farming Management Platform

Document Info
Version 1.0
Status Draft — Business Baseline + Current Documentation Alignment
Created Date 2026-09-16
Last Updated 2026-09-16
Business Owner Product / Business
Reviewers Engineering, QA, Operations, Security
Source Documents 01_PRD — Product Requirements Document.md, 01-product/SRS.md, 01-product/requirements/*, DOCUMENTATION-GAPS.md

Business alignment note: This BRD describes business needs and target outcomes. It does not mean every capability is already implemented. Current implementation status follows the labels CONFIRMED, PARTIAL, PLANNED, FUTURE and TBD.

Table of Contents

  1. Executive Summary
  2. Business Background
  3. Business Objectives
  4. Stakeholders And Users
  5. Business Scope
  6. Business Requirements
  7. Business Rules And Constraints
  8. Business Processes
  9. Data And Reporting Needs
  10. AI Business Requirements
  11. Integrations And Dependencies
  12. Non-Functional Business Expectations
  13. Roadmap And MVP Scope
  14. Success Metrics
  15. Risks
  16. Assumptions
  17. Open Questions
  18. Traceability
  19. Approval
  20. Document History

1. Executive Summary

AquaX is a SaaS/IoT shrimp farming management platform designed to centralize farm operations, pond monitoring, feeding, logs, alerts, tickets, reports, handbook knowledge, IoT device control and AI-assisted decision support.

The business need is to reduce fragmented manual operations and provide a traceable, role-controlled platform for farm owners, technical staff and administrators.

The product direction is:

Manage → Monitor → Alert → Operate → Automate → Recommend → Assist → Predict

Current repository and documentation show that the core platform foundation is partially implemented. IoT ingestion, reports, alerts, farm/pond management and ticket workflows exist in part. AI chatbot, AI prediction, advanced AI feeding and scheduled weekly reporting remain planned or partial.

2. Business Background

Shrimp farming operations involve many activities that must be coordinated across farms, ponds and crop cycles:

  • user responsibilities and farm ownership;
  • pond/crop setup and assignment;
  • water-quality monitoring;
  • manual environmental logs;
  • feeding records and feed response;
  • mineral and siphon records;
  • IoT sensor/device status;
  • alerts and technical incidents;
  • device commands;
  • reports and Excel export;
  • handbook knowledge and technical guidance;
  • AI recommendations and predictions.

Without a centralized system, data becomes scattered, technical issues are harder to trace, and decision-making depends heavily on manual communication.

AquaX addresses this by combining operational data, IoT telemetry and guided decision support under role-based access control.

3. Business Objectives

ID Objective Business Value Status
BO-01 Centralize shrimp farm operational data. Reduce manual tracking and improve traceability. PARTIAL
BO-02 Provide role-based access for Admin, farm owner, technician and technical support roles. Ensure users see only relevant farms, ponds, tickets and AI context. PARTIAL
BO-03 Monitor pond environmental indicators and device/sensor status. Support timely operational decisions. PARTIAL
BO-04 Detect abnormal conditions and trigger alerts. Reduce response delay to pond/device issues. PARTIAL
BO-05 Track feeding, farming logs, minerals, siphon and productivity. Support reporting, analysis and future AI recommendations. PARTIAL
BO-06 Manage technical incidents through ticket workflow and SLA. Improve accountability and resolution tracking. PARTIAL
BO-07 Provide reports and Excel exports. Support farm review, weekly reporting and business analysis. PARTIAL
BO-08 Provide a Farming Handbook. Standardize operational knowledge and support technician guidance. PARTIAL
BO-09 Introduce AI chatbot, image analysis, recommendations and prediction gradually. Improve decision support while keeping safety controls. PLANNED / PARTIAL
BO-10 Prepare for secure, maintainable operations. Support production readiness and business continuity. PARTIAL

4. Stakeholders And Users

4.1 Stakeholders

Stakeholder Interest / Responsibility
Product / Business Owner Owns business scope, roadmap, priorities and acceptance.
Farm Owner / Chủ hộ Needs visibility into farms, ponds, alerts, reports and operations.
Pond Technician / KTV tại hồ Performs field operations, logs data, handles alerts and reports issues.
Technical Support / KTV đội quản trị Receives, processes and closes assigned technical tickets.
System Admin Manages users, farms, ponds, settings, handbook and high-level data.
Engineering Builds backend, web, mobile, IoT and AI integrations.
QA Validates role flows, requirements and release acceptance.
Operations / DevOps Owns deployment, monitoring, backup, incidents and release operations.
Security Reviews access control, audit logging, data protection and AI safety.

4.2 User Roles

Role Business Scope Current Status
Admin System-wide management of users, farms, ponds, configuration, reports and content. PARTIAL
Farm Owner Own farm/pond monitoring, reports, tickets, device actions if enabled and AI usage. PARTIAL
Pond Technician Assigned pond operations, logs, alerts, device actions if enabled and incident creation. PARTIAL
Admin Technical Staff Assigned ticket/incident handling and technical support. PARTIAL
Viewer / Owner-facing user Read-oriented farm overview and activity visibility where enabled. PARTIAL

5. Business Scope

5.1 In Scope

Area Business Scope Status
Authentication and user management Login, logout, reset password, user status, role and scope assignment. PARTIAL
Farm, pond and crop management Manage farms, ponds, active crops, KTV assignment and crop lifecycle. PARTIAL
Water monitoring View pond indicators, safe thresholds, trends, sensor status and history. PARTIAL
Alert management Environmental/device alerts, lifecycle, filters, escalation and guidance. PARTIAL
IoT device control Device list, assignment, command history, manual/auto mode and rules. PARTIAL
Feeding management Feeding records, feed response, actual vs suggested amount and history. PARTIAL
Farming logs Manual environment, mineral, siphon, productivity and daily logs. PARTIAL
Reports and Excel export Water, device, feeding, farming, ticket and weekly reports. PARTIAL
Ticket management Ticket creation, assignment, progress, SLA and email notification. PARTIAL
Farming Handbook Article library, search, filter, favorites, admin workflow and versioning. PARTIAL
Notifications In-app, push and email events by alert/ticket/report/system need. PARTIAL
System configuration Thresholds, automation rules, master data, email, SLA, SaaS plan and AI policy. PARTIAL / PLANNED
AI Chatbot, image analysis, feeding suggestion, recommendations, growth/energy optimization and prediction. PLANNED / PARTIAL

5.2 Out Of Scope / Future Phase

Area Status
SMS, Zalo and automated call channels FUTURE
SSO/OAuth FUTURE
ERP or supply-chain integration FUTURE
Advanced traceability beyond current reporting scope FUTURE
Realtime camera AI FUTURE
Fully autonomous device control without user authorization and safety rules OUT OF SCOPE

6. Business Requirements

6.1 Core Business Requirements

ID Requirement Priority Status
BRD-001 The business needs one platform to manage users, farms, ponds, crops, tickets, reports, handbook and operational logs. Must PARTIAL
BRD-002 The platform must support web and mobile surfaces for role-appropriate workflows. Must PARTIAL
BRD-003 The platform must enforce role and farm/pond/ticket scope for all user-visible data. Must PARTIAL
BRD-004 Farm owners must be able to monitor current pond status, alerts, feeding and reports for their farms. Must PARTIAL
BRD-005 Field technicians must be able to input daily operational data quickly. Must PARTIAL
BRD-006 Admins must be able to configure users, farms, ponds, thresholds, SLA and system data. Must PARTIAL
BRD-007 The system must support technical incident management and escalation. Must PARTIAL
BRD-008 Operational history must be preserved for traceability and reporting. Must PARTIAL
BRD-009 AI capabilities must be implemented gradually with safety controls, references, logging and fallback. Should PLANNED / PARTIAL
BRD-010 The business must be able to distinguish delivered features from planned roadmap items. Must CONFIRMED

6.2 Operational Requirements

ID Requirement Priority Status
BRD-OP-001 Users must be able to access only assigned farms, ponds or tickets. Must PARTIAL
BRD-OP-002 Pond dashboards must combine water metrics, crop context, sensor status and alert state. Must PARTIAL
BRD-OP-003 Alerts must show severity, source, lifecycle status and next action. Must PARTIAL
BRD-OP-004 Device commands must be logged with requester, command, timestamp, execution status and response. Must PARTIAL
BRD-OP-005 Ticket workflow must preserve SLA and processing history. Must PARTIAL
BRD-OP-006 Reports must respect user scope and avoid cross-farm data leakage. Must PARTIAL
BRD-OP-007 Weekly scheduled reports should reduce manual reporting effort. Should PLANNED

6.3 Knowledge And Decision Support Requirements

ID Requirement Priority Status
BRD-KD-001 Handbook content must be searchable, filtered and versioned. Must PARTIAL
BRD-KD-002 Handbook articles referenced by AI must not be hard-deleted. Must PLANNED / PARTIAL
BRD-KD-003 AI answers must cite approved sources or pond data where applicable. Should PLANNED
BRD-KD-004 Serious or low-confidence AI outputs must suggest KTV/ticket fallback. Should PLANNED
BRD-KD-005 Rule-based recommendations may be used before AI-based recommendation. Should PLANNED

7. Business Rules And Constraints

7.1 Business Rules

Rule Description Status
Role and scope filtering Every protected query/action must respect role and farm/pond/ticket scope. PARTIAL
Disabled account preservation Disabled users cannot log in, but their historical actions remain traceable. PARTIAL
Closed crop protection Closed crop data should be read-only except for users with special permission and audit. PARTIAL
Device command logging Every command must be logged and tied to user/device/context. PARTIAL
Device non-response Non-responsive device commands must trigger timeout state and alert behavior. PARTIAL
Ticket SLA Tickets past SLA must escalate according to configuration. PARTIAL
Handbook reference integrity AI-referenced content must remain recoverable. PLANNED / PARTIAL
AI safety AI recommendations support decisions but do not replace technicians or user confirmation. PLANNED

7.2 Constraints

Constraint Impact Status
Temporary auth-scope bypasses exist in current code. Production risk until removed and tested. OPEN
IoT device behavior depends on broker/gateway reliability. Production IoT operations need hardening. OPEN
PCR/FCR and productivity formulas remain unapproved. Related metrics and AI logic cannot be accepted. OPEN
Push provider and notification SLA are not confirmed. Mobile notification acceptance is incomplete. OPEN
Offline sync strategy is not defined. Mobile offline acceptance cannot be completed. OPEN
AI model/service selection is not confirmed. AI roadmap remains planned. OPEN

8. Business Processes

8.1 Global Operational Flow

  1. User logs in.
  2. System validates session and loads role/scope.
  3. User opens dashboard.
  4. User selects farm and pond.
  5. User monitors water metrics, device status and farming logs.
  6. If normal, user continues daily monitoring/logging.
  7. If warning/alert, user opens alert, acknowledges, takes action and closes.
  8. If device issue, user creates/opens ticket, assigns/processes/closes.
  9. If guidance is needed, user opens handbook or chatbot.
  10. System records actions and preserves history.

8.2 Alert Process

  1. Sensor, device or user event occurs.
  2. System evaluates threshold/rule.
  3. System creates alert if condition matches.
  4. System notifies configured recipients.
  5. User acknowledges alert.
  6. User takes action: note, device command, ticket, handbook or chatbot.
  7. User closes alert when resolved.
  8. System escalates if timeout/SLA is reached.

8.3 Ticket Process

  1. User creates ticket with pond/device/description/attachment.
  2. System sends configured email/notification.
  3. Admin or system assigns technical staff.
  4. Technical staff accepts and processes.
  5. Ticket is updated with progress and evidence.
  6. Ticket is closed with resolution.
  7. SLA metrics are recorded.

8.4 Chatbot Process

  1. User opens chatbot.
  2. User selects pond context if applicable.
  3. System validates authorization.
  4. Chatbot uses approved handbook and permitted pond data.
  5. Chatbot responds with confidence and references.
  6. If risk is high or confidence low, chatbot suggests KTV/ticket fallback.
  7. User rates answer or creates ticket.

9. Data And Reporting Needs

9.1 Data Domains

Domain Business Need Status
Identity and access Role, scope, account status and session traceability. PARTIAL
Farm/pond/crop Business hierarchy for all operations and reports. PARTIAL
Water/sensor data Monitoring, alerts, AI prediction and historical analysis. PARTIAL
Device commands Traceability and safety for IoT control. PARTIAL
Feeding/logs/productivity Daily operations, reports and AI recommendations. PARTIAL
Alerts/tickets Incident lifecycle, SLA and escalation. PARTIAL
Handbook Operational knowledge and AI source references. PARTIAL
Notifications Event delivery and user follow-up. PARTIAL
AI interactions AI logging, feedback, references and escalation evidence. PLANNED

9.2 Reporting Needs

Report Business Purpose Status
Water monitoring report Review pond water metrics and threshold breaches. PARTIAL
Device report Review runtime, commands, failures and energy optimization. PARTIAL
Feeding report Review feed amount by session/day/week/crop and PCR/FCR when approved. PARTIAL
Farming operation report Review manual environment, minerals, siphon and productivity. PARTIAL
Ticket report Review response time, resolution time, SLA and handler. PARTIAL
Handbook/chatbot report Review usage, common questions and feedback. PLANNED
Weekly report email Automated recurring business summary. PLANNED

9.3 Retention Expectations

Retention targets are not fully approved. Baseline SRS expectations:

Data Type Minimum Retention Status
Sensor data 1 year. TBD
Device history 1 year. TBD
Feeding/manual logs/minerals/siphon Full crop history across multiple crops. PARTIAL
Alerts/tickets/audit logs At least 1 year. TBD
Handbook content Permanent by version. PARTIAL
Chatbot history/images At least crop lifecycle; privacy policy TBD. PLANNED

10. AI Business Requirements

AI capabilities must be phased and controlled. AI output is decision support only.

ID AI Capability Business Purpose Phase Status
AI-01 Text chatbot Help users ask operational questions based on handbook and pond data. MVP 3 PLANNED
AI-02 Image analysis Provide preliminary assessment from shrimp/water/feed tray/pond bottom/device images. MVP 4 PLANNED
AI-03 Feeding recommendation Suggest daily/per-session feed amount and optimal time window. MVP 4 PLANNED
AI-04 Growth/productivity assessment Assess shrimp growth and productivity trends. MVP 4 PLANNED
AI-05 Alert recommendation Detect abnormal conditions and suggest response; may start rule-based. MVP 2-4 PARTIAL / PLANNED
AI-06 Energy optimization Suggest device schedules to reduce electricity use. MVP 3-4 PLANNED
AI-07 Prediction Predict water quality trend, alert risk, feed need, growth, harvest window and device/energy risk. MVP 3-4 PLANNED

AI Control Requirements

Control Business Requirement
Authorization AI can use only authorized farm/pond/crop/device context.
References AI must cite approved handbook or data sources when applicable.
Confidence AI must show confidence/uncertainty and avoid definitive claims where evidence is weak.
Logging AI prompts/context metadata/results/references/feedback/escalation must be logged under privacy rules.
Fallback Low-confidence or serious cases must route to KTV/ticket workflow.
No dangerous automation AI must not directly execute device control or critical operational change without user confirmation and authorization.

11. Integrations And Dependencies

ID Integration / Dependency Business Need Status
INT-01 Sensor data ingestion Receive sensor data for monitoring, alerts and AI. PARTIAL
INT-02 Device control gateway Send commands and receive responses. PARTIAL
INT-03 Email service Reset password, tickets, escalation and weekly reports. PARTIAL
INT-04 Push notification Mobile notifications for alerts/tickets/events. PARTIAL / PLANNED
INT-05 Object storage Store ticket media, chatbot images and report files securely. PARTIAL
INT-06 AI/LLM service Chatbot, image analysis and recommendations. PLANNED
INT-07 Future channels SMS, Zalo and automated calls. FUTURE
DEP-01 PostgreSQL/TimescaleDB Core and telemetry data. CONFIRMED
DEP-02 Redis Runtime cache/session support. CONFIRMED
DEP-03 MQTT/Mosquitto/Telegraf/IoT worker IoT ingestion and device pipeline. CONFIRMED / PARTIAL

12. Non-Functional Business Expectations

Area Business Expectation Target / Note Status
Security HTTPS, protected sessions and strict RBAC. Production HTTP must be disallowed. PARTIAL
Authorization API and UI must not leak cross-scope data. Cross-farm denial tests required. PARTIAL
Availability System should support operational usage. Legacy target 99.5%, not yet approved. TBD
Performance Dashboard and sensor APIs must respond quickly. Legacy: dashboard < 3s, sensor API < 1s. TBD
Export performance Excel export should complete in acceptable time. Legacy: < 30s for 1-year single farm/pond, or background job. TBD
Notification delivery Notifications should be timely. Legacy: push/in-app < 30s, email < 5 min. TBD
Offline mobile Mobile should support basic cache/sync in field conditions. Conflict strategy TBD. PLANNED / PARTIAL
Auditability Important actions must have audit logs. Scope and retention TBD. PARTIAL
Scalability Multi-farm/owner usage must remain isolated. Tenant isolation via scope/farm/owner. PARTIAL

13. Roadmap And MVP Scope

Stage Business Scope Status
MVP 1 Authentication, roles, farm/pond, six-metric dashboard, basic sensor cadence, environmental alerts, device on/off, command history, technical ticket and email. PARTIAL
MVP 2 Feeding entry, manual pH/alkalinity/mineral/siphon logs, daily/weekly/crop reports, Excel export, KTV assignment and basic handbook. PARTIAL
MVP 3 Rule-based energy optimization, device runtime analysis and text chatbot based on handbook/pond data. PARTIAL / PLANNED
MVP 4 AI feeding suggestion, feeding-time prediction, growth assessment, PCR/FCR/productivity analysis and image chatbot. PLANNED
Future Phase SMS/Zalo/calls, SSO/OAuth, ERP/supply-chain integration, advanced traceability and realtime camera AI. FUTURE

Recommended business sequencing:

  1. Close auth/scope gaps.
  2. Complete farm/pond/crop, alert, log, report and ticket workflows.
  3. Harden IoT ingestion and device command operations.
  4. Complete reporting automation and notification templates.
  5. Add AI only after source data, handbook references, permissions and logging are stable.

14. Success Metrics

Approved targets are still TBD. Recommended metrics:

Metric Purpose Target
Active farms/ponds using platform Adoption. TBD
Environmental records captured IoT/data completeness. TBD
Alert acknowledgement time Operational response. TBD
Ticket response/resolution time Support SLA. Configured SLA
Device command success rate IoT reliability. TBD
Report generation success rate Reporting reliability. TBD
Weekly report delivery rate Automation success. TBD
Feeding suggestion usage rate AI/decision-support adoption. TBD
Chatbot helpful response rate Knowledge support quality. TBD
AI escalation rate Safety and uncertainty tracking. TBD
Unauthorized data exposure Critical quality indicator. 0 expected

15. Risks

Risk Business Impact Mitigation Status
Authorization gaps expose cross-farm data. Critical trust/security risk. Remove bypasses and add regression tests. OPEN
Planned features are mistaken as delivered. Misaligned expectation and release risk. Keep explicit status labels in PRD/BRD/SRS. OPEN
IoT device non-response is not fully alerted. Operational risk at pond. Complete timeout-to-alert behavior. OPEN
AI confidence/source rules are undefined. Unsafe or unverifiable recommendations. Define AI safety and acceptance criteria. OPEN
PCR/FCR formula not approved. Reports/AI feeding cannot be accepted. Domain approval required. OPEN
Production monitoring/backup not defined. Operational continuity risk. Define SLO, RPO, RTO and providers. OPEN
Offline sync conflicts not defined. Field mobile data conflict risk. Define conflict resolution rules. OPEN
Large exports may block users. Reporting performance risk. Confirm background export strategy. OPEN

16. Assumptions

ID Assumption Status
AS-01 Web and mobile both support role-based workflows, but layouts/actions differ by surface. PARTIAL
AS-02 Six default water indicators include pH, DO, salinity, algae/ORP, alkalinity and temperature. TBD
AS-03 Sensor data cadence is around 20 minutes in MVP unless devices support faster updates. TBD
AS-04 Device control is high risk and requires permission, logging and safe error handling. CONFIRMED
AS-05 AI recommendations assist decisions and do not replace human operators or technicians. CONFIRMED
AS-06 Rule-based recommendations may be accepted before full AI-based recommendations. CONFIRMED

17. Open Questions

ID Question Owner Priority
OQ-01 What is the approved PCR/FCR formula? Domain/Product Blocker
OQ-02 Should algae be represented as algae, ORP or another indicator? Domain/Product High
OQ-03 Are thresholds global, farm-specific, pond-specific, shrimp-type-specific or stage-specific? Product/Domain High
OQ-04 Can the system automatically control devices, or must users confirm actions? Product/Tech Blocker
OQ-05 How many devices and sensors can each pond support? Product/Architecture High
OQ-06 Will sensor/device data be pushed or pulled in production? Product/IoT High
OQ-07 Who is the configured technical supervisor for ticket emails/escalation? Product/Ops Medium
OQ-08 What is the official productivity measurement method? Domain/Product High
OQ-09 What are siphon units and evidence requirements? Domain/Product Medium
OQ-10 What offline sync conflict rule applies when multiple users edit the same record? Product/Mobile High
OQ-11 Which AI model/service and knowledge sources are approved? Product/AI/Security High
OQ-12 What retention policy applies to telemetry, audit logs, ticket media and chatbot history? Security/Ops High
OQ-13 Should large reports run synchronously or as background jobs? Product/Backend High
OQ-14 What production SLA/SLO, RPO and RTO are required? Product/Ops High

18. Traceability

BRD Area Current Docs
Product requirements 01_PRD — Product Requirements Document.md, 01-product/PRD.md
Software requirements 01-product/SRS.md
Business requirements 01-product/requirements/business-requirements.md
Functional requirements 01-product/requirements/functional-requirements.md
Data requirements 01-product/requirements/data-requirements.md
Business rules 01-product/requirements/business-rules.md
Permission matrix 01-product/requirements/permission-matrix.md, 08-security/access-control.md
Acceptance criteria 01-product/requirements/acceptance-criteria.md, 06-testing/test-cases.md
Roadmap 01-product/roadmap.md
User flow and screens 03-design/user-flow.md, 03-design/screen-list.md
Architecture and integrations 04-architecture/system-architecture.md, 04-architecture/integrations.md
Risks and gaps 02-project/risks.md, DOCUMENTATION-GAPS.md

19. Approval

Role Name Decision Date
Business Owner TBD TBD TBD
Product Owner TBD TBD TBD
Engineering Lead TBD TBD TBD
QA Lead TBD TBD TBD
Operations/Security TBD TBD TBD

20. Document History

Version Date Author Changes
1.0 2026-09-16 Product Team Created complete BRD from current PRD, SRS, requirement files, roadmap and documentation gaps.

End of Business Requirements Document